Dynamic Remediation Functions and Mapping to override default hier_config#770
Dynamic Remediation Functions and Mapping to override default hier_config#770sdoiron0330 wants to merge 7 commits intonautobot:developfrom
Conversation
sdoiron0330
requested review from
itdependsnetworks,
jeffkala and
nkallergis
as code owners
jeffkala
left a comment
jeffkala
left a comment
There was a problem hiding this comment.
Will do a deeper review shortly; however, first thing that is a must before we can merge is:
- Must have docs
- Should have at least a few TestCases.
|
|
||
|
|
||
| class DynamicRemediationMappingForm(NautobotModelForm): | ||
| """Form for ConfigPlan instances.""" |
|
I am trying to find a right balance between usability and configuration overhead -when we introduced Remediation, we also implemented Custom Remediation which could solve this use case too. What I understand from example functions is what we try to solve by implementing those remediation methods, will probably be applicable for 80% use cases. I don't think each user should create Remediation settings first , then also create multiple "Dynamic Remediation Mappings" - perhaps we could integrate this under "remediation settings" jsonField, or straight (natively) into HierConfig ? |
|
Can I get a bit of a better explanation as to what this is doing? I am not really understanding the use case or the strong driver for an additional model. |
#755 covers what this is trying to solve. A few months back there was an ask in public slack around customizing the way ACLs were being generated/remediated via Heir_config. James mentioned a custom remediation function from the heir_config side of the house, this allows for creating and syncing in custom remediation functions from Git. |
|
Can we just set it up to have a flavor of custom remediation? E.g. add |
| ) | ||
|
|
||
|
|
||
| def refresh_git_gc_dynamic_remediations(repository_record, job_result, delete=False): # pylint: disable=unused-argument |
There was a problem hiding this comment.
I haven't looked at the code, but this part makes sense, I think that this is mostly what needs to be updated, more specifically there shouldn't be a reason to create a new model here.
There was a problem hiding this comment.
I think it should be possible to have a similar solution :
- custom remediation method is provided via nautobot_config.py or packaged
- custom remediation points to a dispatcher provided by git.
There was a problem hiding this comment.
made some changes to remove the model and just load modules from the git repo when doing remediation; lmk what you think
|
Would like to pursue 2 things.
@jeffkala to take lead at point 1. |
|
I still think what is needed is the integration under "Custom Remediation". We have already built a pattern that now can be extended for git , without the need of introducing the third Remediation Type. The existing |
| ComplianceRuleConfigTypeChoice.TYPE_JSON: _get_json_compliance, | ||
| ComplianceRuleConfigTypeChoice.TYPE_XML: _get_xml_compliance, | ||
| RemediationTypeChoice.TYPE_HIERCONFIG: _get_hierconfig_remediation, | ||
| RemediationTypeChoice.TYPE_DYNAMIC_HIERCONFIG: _get_hierconfig_remediation, |
There was a problem hiding this comment.
This is not tracking to me, we are pointing it to the same function of _get_hierconfig_remediation(), which would indicated to me, it's the same feature with a different name, but I think I am missing something, can you elaborate on this one?
There was a problem hiding this comment.
i added that as an option so that if your environment had dynamic functions loaded via git and for a particular remediation setting you didn't need or want to use any dynamic functions at all, it bypassed that loop over the dynamic functions entirely
4 participants
CLOSES #755
Adds
DynamicRemediationFunctionandDynamicRemediationMappingmodels to import functions from a Git Repository that should be run during Config Compliance when remediation config is generated.STILL TODO: